ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group98a.txt/000122_icon-group-sender _Wed Mar 11 16:24:55 1998.msg

Internet Message Format | 2000-09-20 | 7KB

Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
    by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id QAA00606
    for <[e-mail]>; Wed, 11 Mar 1998 16:24:54 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA13332; Wed, 11 Mar 1998 16:24:54 -0700
From: [e-mail]
Date: Wed, 11 Mar 1998 14:08:18 -0600
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Subject: Re: Translation into C
To: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
X-Mailer: SPRY Mail Version: 04.00.06.17
Errors-To: [e-mail]
Status: RO
Content-Length: 6473

[MATLAB]

> "The Compiler and Library products offer MATLAB users execution
speedups, code hiding, and the ability to automatically generate
standalone C and C++ applications. By automating the conversion of
M-files into C and C++ source code, the MATLAB Compiler and Math
Libraries eliminate time-consuming and error-prone manual translation
and reduce development time for applications that run outside the MATLAB
environment."

> -- http://www.mathworks.com/products/compilerlibrary/

> We have here a case study of the desirability of C++ conversion.  A
commercial company with a stable product decides it is worth investing a
lot of money to develop C++ conversion.  Hmm...

That's really a TOTALLY separate issue.

>From their perspective, clearly it's easier to generate C/C++ code than to
generate a direct executable.  It eliminates them having to worry about the
details of memory models, address resolution, executable file formats, I/O and
other runtime library functions, and all the rest.  All they have to crank out
is C code in generic text file format, and the resulting program can presumably
be compiled for most systems with a good production-quality C compiler.
(Remember that C is really not a whole lot more than a symbolic assembler
language).

Also, this kind of number-crunching program tends to be heavily compute-bound,
and with highly direct, clear-cut translation of the arithmetical processing to
be done... probably with a lot of custom-generated inline code.  So for their
purposes, a generic interpreter (whether Icon-type or even Java-type for that
matter) is less interesting.

Icon on the other hand already has an interpreter written in C (thus very easily
ported to other systems, as evidenced by the wide array of environments where
Icon is already supported) and has the characteristic that many of the language
functions are complex enough that they aren't likely to be done in inline code
in any case.  Clearly once you get into the "runtime library" (where a language
like Icon spends a lot of its time), the application IS being directly executed.

And as for "worth investing a lot of money", certainly there's nothing
PREVENTING a for-profit company that decides that this is true from writing an
Icon compiler which would generate C/C++ code.  Frankly, I don't think you're
very likely to see that happen.  Remember that Icon is available for our use due
to a **research project** which we've been fortunate enough to reap the benefits
of.  It is apparently the judgement of the people doing that research (up to now
at least... and I concur) that there are other things which would be far more
useful to add to the language than to have their development project schedule be
jerked around by someone just because THEY *THINK* that it would be cool to
crank out C or C++ code.

If someone were going to take on a big addition to Icon, frankly, I'd far rather
see support added for some kind of databases... whether simple ISAM files, or
(perhaps better) ODBC or some other kind of generic database support.  This is
at present one of the biggest holes in the language, since nearly all
business-oriented applications are based on [multiple?-]keyed, related databases
of some kind each with multiple-field records.  Going with a "standard" database
implementation would allow one to use Icon with diverse database systems
(FoxPro, Access, even Oracle or some such) so that it could access the same
corporate data as the other systems in the company use... and would allow a much
easier "foot in the door" to permit Icon to get a foothold in many companies.

And again regarding "worth investing a lot of money", where and how do you
propose that one might envision seeing a genuine return of that money
"invested"?  As it is, most people don't pay for Icon (and even with the product
being essentially FREE it's not clear that it's exactly setting the programming
world on fire... unfortunately).

So anyhow, while people could speculate nearly endlessly about what the
characteristics might be of an Icon implemented such that the compiler cranked
out ["maintainable", no less!!!  And I think this is the silliest aspect of all]
C/C++ code, the _fact_ is that that is _not_ the way that Icon was implemented,
and I doubt that's going to change anytime real soon.  Use Icon, and enjoy its
many wonderful and unique features.  I think people should quit griping about
how it's implemented!

As a product developer myself, I know just how easy it is for outside people to
try to set the agenda for the developer... it's easy for them (not understanding
what's involved, and of course not being willing to cough up the money either)
to propose grand visions of work which would perhaps take many man-years to
complete.  It's especially absurd when the product doesn't even make sense to
begin with, and probably wouldn't be worth having if anyone DID do all that
work.

And that's what I was alluding to in the "silly" comment above.  The reason
people write a program in a language like Icon is because it's HUGELY simpler
than writing in C/C++.  But once a program is initially written, it's rarely
"done" (other than one-shot programs of course) and then it enters the
"maintenance/use/upgrade" part of the software life cycle... usually much longer
than the time it took to write the program to begin with.  And if it made sense
to WRITE the program in Icon to begin with, you'll probably want to maintain and
enhance it ALSO from the Icon source.  Once you start dicking around with the
C/C++ source code, you'll then lose those changes when you enhance and recompile
the program from the Icon source code.

So I really think that people ought to just use Icon and enjoy it for what it
is!!  It really is a terrific language, highly useful, and I think it's sorta
ludicrous to presume that it makes sense to spend (waste!) a lot of time
cranking out C/C++ source code (and TRYING, probably unsuccessfully, to make it
such that the program might be maintainable at that level... clearly few
applications programmers are ever going to understand enough about the Icon
implementation internals and rules to be able to successfully modify a program
where all those internal details and programmer pitfalls are right out there in
the open).

Gordon Peterson
http://www.computek.net/public/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/